The 640 MEG Shareware Studio 2

home *** CD-ROM | disk | FTP | other *** search

/ The 640 MEG Shareware Studio 2 / The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO / door / wa_137.zip / CONFIG.TXT < prev next >

Wrap

Text File | 1992-09-26 | 20KB | 498 lines

WIZARD'S ARENA -- RELEASE 1.37 (C) Copyright 1991,1992 by Douglas Summers CONFIGURATION ────────────────────── THE CONFIGURATION FILE ────────────────────── Beginning in version 1.22, WIZARD'S ARENA will get its parameters from a text file rather than from the command line. This file is named "CONFIG.WA". Running the upgrade program will generate an initial CONFIG.WA, which you may then edit using any simple-ASCII text editor. If none was made, then you should begin with a nice, blank one. CONFIG.WA is a simple text file, made up of individual lines. Each line is of the format "aaaa=bbbb" where "aaaa" is the name of some parameter and "bbbb" is the value to be assigned to it. For example, the line BBSNAME = The Truly Massive BBS is used to set the name of the BBS to be "The Truly Massive BBS". The equals-sign may be preceded or followed by any number of spaces. The line, as well, can have spaces before the parameter-name and after the last character of the value. Such spaces will be ignored. The values are case-insensitive: BUT THE EXCEPTION IS THE BBS NAME, which IS case-sensitive. You'll note that a lot of the configuration options are related to error-correction. This doesn't mean that the game is particularly flimsy; they're mostly stuff I found useful in developing/debugging and saw some real-world use for. ─────────────────────────── GENERALLY-AVAILABLE OPTIONS ─────────────────────────── BBSNAME ─────── This sets the name of the BBS. You MUST have this one, and, unlike all the others, is case-sensitive. Please, please note that the name, once you've registered, must remain fixed. Changing it will invalidate your registration, and you'll have to contact me give you a new registration sequence. DEBUG ───── This forces extensive debugging information to be collected. DON'T USE THIS UNLESS YOU REALLY NEED IT. There is no built-in method to clean up the huge ERRORS.OUT file that will be generated. Turn this on with "DEBUG = Y" -- anything else means debugging is off. REMOTECOLOR ─────────── This is used to set the color the user's screen is set to when the program terminates. There are 16 possible settings: BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, DINGY (lo-intensity white), GRAY (hi-intensity black), HIBLUE, HIGREEN, HICYAN, HIRED, HIMAGENTA, YELLOW and WHITE. LOCALCOLOR ────────── Like REMOTECOLOR, but applies to the local terminal. PARANOID ──────── Used to disable the "backdoor" functions. These functions are debugging aids that the author thought might be handy to leave in, because they can be used to perform a certain amount of in- situ diagnosis. They are available as unlisted commands. To see them, type "&" for your action; nothing will happen; then enter one of the following: "M" shows memory available "E" dumps out the error log "S" prints out certain game statistics "K" echoes back key-codes There aren't any others. Unless you're REALLY, REALLY afraid that this information seriously compromises your BBS, you might want to leave them available in the event a problem DOES occur. Turn this on with "PARANOID = Y" -- anything else means that paranoia is off (the functions are available). PORT ──── If you have nonstandard comm port or are using a fossil driver, you can tell the game about it with the PORT parameter. The format for this parameter is: "PORT = aaa:i", where "aaaa" is the base address and "i" is the interrupt. For example, "PORT = 02F8:3" sets the system to use a com-port whose base address is 02F8 and which uses IRQ 3. For fossil drivers, use "PORT = F:n" where "n" is the number of the com-port to use the fossil driver on. DOORFILE ──────── Gives the full path-and-filename of the BBS's door-information file. This parameter can be overridden by the command-line, but if no parameter is given there, then this is the file used. SEMAPHORE ───────── WIZARD and WA-UTIL make a special semaphoring file to prevent either program from running while the other is active. If the various nodes of a LAN BBS have their real-time clocks seriously out-of-sync, the technique employed becomes useless. If that is the case, set semaphoring off via a "SEMAPHORE = NO" line, and handle such protection in your batch file. ─────────────────────────────────────────── OPTIONS AVAILABLE ONLY TO REGISTERED SYSOPS ─────────────────────────────────────────── After you've played the game and been vastly impressed by the sheer genius of it, you can send me money. I'd like that. (The SYSOP.TXT file gives details on how much and where; for now, I'll take it as read that you've done that.) What you'll get back for your hard-earned cash is an eight-digit registration code. You should put it in your CONFIG.WA file, where the game can find it and reward you for your generosity. You will, at that point, have access to a number of other parameters which will allow you a fair amount of customization. APDIV, APMULT ───────────── Every creature in the game -- monsters and players alike -- receive a certain number of Action Points (APs) every day. These determine how much a creature can do; every action (with only 1 or 2 exceptions) costs APs, and when a creature uses up its APs, it has to stop for the day. These two parameters help determine how many APs everyone gets. The process is: If a creature has an Agility of less than (or equal to) 15, it gets a number of APs equal to its Agility rating. If its Agility is 16 or more, it gets 15 AP, plus a certain number determined by this formula: ((Agility - 15) * APMULT) / APDIV For example, let's say you've set up "APMULT = 2" and "APDIV = 3". A creature with an agility of 5 gets 5 AP (and is pretty much a sitting duck). Another creature, with an Agility of 47, will get ((47 - 15) * 2) / 3 = 21 AP. Why would you want to do this? If we simply let the number of AP equal the Agility rating, a player could quickly get to a rating of 50 or more -- which would allow him a great many attacks, if he didn't have to move far to get to his target. If his target is a monster, that's not so bad -- but if its a player, it isn't really fair. The other player could be taken completely unawares and be destroyed by someone he didn't even know was there. In a sense, these values set the "dangerousness" of the game: the degree to which a player must take precautions against unexpected attacks. MONSTERSPEED ──────────── If you want the players to be mobile, but not the monsters, then simply setting APMULT high won't really accomplish what you want. The monsters will also be fast -- and if one happens to "pop in" adjacent to a player, he could get in a great many whacks before the player has a chance to do anything about it. The MONSTERSPEED parameter determines the rate at which the monsters expend AP to do things. For example, if the MONSTERSPEED is 0, it costs them 5 times as many AP to do anything as it does the players -- which means that they're slow and don't attack often. Setting it to 9 makes them about twice as mobile as the players -- and very dangerous. (It can be set all the way to 20). If you want the players to focus on each other, set MONSTERSPEED low; if you want them to become monster-obsessed, set it high. ABSENCES ──────── The game only allows 64 players. If players try the game once, and never come back, then their player-records would sit around forever. The game, to get around this, counts the number of "absences" a player has (the number of days since he last played). If that number exceeds the ABSENCES value, his character suffers a heart attack and leaves a corpse on the map, and his player- record is made available for the use of other people. Setting this value low is probably unfair; setting it too high might cause the clogging earlier mentioned. The default value of 14 seems reasonable, but your circumstances might dictate something else. TRAINCOST, TRAINSLOPE ───────────────────── Players gain experience by killing monsters (or other players). They trade experience points (via the "Train" command) for higher characteristic values, or for spell proficiency. This has the net effect of making them more powerful. By default, it always costs 100 XP to train. These two parameters allow you to change that. TRAINCOST determines the number of XP necessary to train the first time. Each successive training costs the same amount, multiplied by 1% of the TRAINSLOPE value. an example will make that clearer. Lets say you've set "TRAINCOST = 50" and a "TRAINSLOPE = 250". A player will need 50 XP to train the 1st time, 50 * 2.50 = 125 XP to train the 2nd time, 125 * 2.50 = 312 XP to train the 3rd time, 312 * 2.50 = 780 XP to train the 4th time, and so on. The net effect is to make it harder and harder to train, so that players do not too quickly become massively powerful. This particular TRAINSLOPE value, though is much too steep. It was chosen as an example only. I more reasonable value might be "TRAINCOST = 50" and" TRAINSLOPE = 110": 50 XP to train the 1st time, 50 * 1.10 = 55 XP to train the 2nd time, 55 * 1.10 = 60 XP to train the 3rd time, 60 * 1.10 = 66 XP to train the 4th time, and so on. It will never cost more than 20000 XP to train. Players begin with an XP allotment of eight times the TRAINCOST value. MONSTERPROB, OBJECTPROB ─────────────────────── The daily maintenance routines put out monsters and random objects like swords and shields. Each space on the map is examined, and may have a monster or object put into it if it is already empty (and if the type of the terrain permits). The probability each space has of generating a monster is given by MONSTERPROB; the probability of generating an item is given by OBJECTPROB. Both are expressed in "chances per 10000" form. For example, lets say you have set "MONSTERPROB = 80" and "OBJECTPROB = 100". This means that each empty space has a 0.8% chance of getting a monster each day; a space that doesn't get a monster has a 1.0% chance of getting an object. These probabilities might not sound like much, but over the whole map, they add up. The map is (at present) 100 x 50 -- the settings indicated would generate about 40 monsters PER DAY -- and about 50 objects. There is an added complication, however: not all of the map is necessarily given a chance to generate. Only the areas around the players can generate. This keeps huge numbers of monsters and objects from being generated in unvisited rooms and hallways, thereby clogging the system. MAGICPROB ───────── This gives the probability (in chances per 10000) that a given object dropped during daily maintenance will be enchanted. It defaults to zero, so non-registered sysops never get this. EXTERMINATION ───────────── Monsters that are far away from any player are pretty much useless. They wander around, taking up precious time during the daily maintenance and no-one would ever miss them if they disappeared. So the system may decide to simply erase them. It will do so a certain percentage of the time, as given by the EXTERMINATION parameter. It is expressed in 10ths-of-a-percent form, so an "EXTERMINATION = 250" gives each such "lonely" monster a 25% chance of being snuffed out each day. Monsters Controlled by players, and those under spells, and those carrying "interesting" items, are exempt from this form of extermination. CACHE ───── The game internally caches certain database operations for reasons of efficiency. If the game is running a little slow on your BBS, try setting the this option to higher values. (It isn't a simple number-of-kilobytes measure). Experimentation will probably pay off, and can't hurt you. Try "CACHE = 300" for best results. If the system can't allocate that much (it would take about 64k), then it will automatically downscale the cache and try again. I've found that this doesn't make as much difference as one might hope; there's roughly a 30% speedup with "CACHE = 300" (which is the maximum). A REAL disk cache would make a LOT more difference. TIMEALLOWED ─────────── Allows you to set the maximum time (per day) that a player can stay in the game. For the unregistered sysops, that number is equal to the players' total remaining time on the BBS. For registered sysops, it is the lower of that value and the value provided with this option. (Multiple entrances to the door will NOT allow the player more time -- it adds up). I don't think this one will matter much to most people, since it seems that a typical "session" of WIZARD'S ARENA is not very long. Still, if you want to limit your players to only 5 minutes, use "TIMEALLOWED = 5". HELLOMSG ──────── If you want to send a short message to all the players as they log onto the game, you can assign one with the HELLOMSG parameter. Simply make a line like the following: HELLOMSG = Your sysop sends you greetings, mortal. and the user, after seeing his mail will see that on in the text-area of the screen, just before the "You are in Wizard's Arena" line. You could, for example, use this to remind non- registered users that they might like to register. AUTOSAVE ──────── Setting this parameter on (i.e., "AUTOSAVE = Y") will cause the game to back up the databases before the game, and, if an error occurs, to restore from this backup when the next player logs in. This won't obviate all errors -- some types of error might cause the game to terminate OK but leave the databases in a bad state, for example. It by no means replaces regular backups. REGISTRATION ──────────── Sets the key sequence -- see SYSOP.TXT for details on registration. STARTBONUS ────────── A player is given a certain number of extra AP on the first day he's in the game. The default is 10; this option lets you change that value. Setting it higher lets new players move around more, explore farther and play longer on their first move, which lets them have a greater chance of survival. AUTOVALIDATE ──────────── When a player enters the game after another player has bombed out, the system will try to fix the databas. The map, for example, can be corrected from a copy kept of the original map. If a persistent problem comes up, you can set this option on (via "AUTOVALIDATE = Y") to force validation even if the system hasn't bombed out. FRATERNITY ────────── You can disallow fraternity membership to your players by setting "FRATERNITY = N". The idea here is that if you maintain seperate configurations for your registered and unregistered users, it becomes possible to only allow registered users to join frats. By default, "FRATERNITY = Y", meaning that players by default are able to join frats. MIDNIGHT ──────── The game uses the computer's real-time clock to determine if daily maintenance should be run. This is perfectly reasonable, unless you do the maintenance off-line at some hour other than midnight. If this is the case, a user who logs in AFTER midnight but BEFORE your off-line processing will trigger the daily maintenance. You can change this by telling the game never to perform daily maintenance before a certain time of day. If, for example, your off-line stuff happens at 4:30, you might set "MIDNIGHT=4:45" (to allow some leeway). The WA-UTIL program will IGNORE this parameter -- it is assumed that the time you call WA-UTIL is when you want the maintenance to occur. FREEMOVE ──────── For sysops who like a more wide-open game, movement can be made free (for players). By setting "FREEMOVE = Y", all players (but not monsters) will be allowed to move as far as they like each day. MAPPING ─────── If there is a shortage of RAM, sysops can turn the MAPPING feature off. This will only save about 1K, though. SPELLTHRESHOLD ────────────── If spell "A" is a prerequisite for spell "B", then a player must have a proficiency of SPELLTHRESHOLD with spell "A" to study spell "B". By default, the value is 80. GARBAGE ─────── This parameter gives the percentage chance for a "generic" item to be cleaned up (destroyed and removed from the map). Items will only be destroyed if they are not carried, and if they have no spells on them. The percentage chance is per day, per item and defaults to 0. If your map tends to get cluttered with swords and shields and whatnot, set this parameter higher (to 10 or even 20, for example). ────────────── A FURTHER NOTE ────────────── Monsters move entirely during daily maintenance. So setting MONSTERSPEED high when you have a lot of monsters running around will make the daily maintenance go slowly -- perhaps several minutes. The same caveat applies to the APMULT and APDIV parameters: if monsters have a lot of AP to spend, they'll take a little longer to spend it. So experiment around with good trade-offs between the speed of your system and the effects you want to produce. ──────────── THE DEFAULTS ──────────── Your CONFIG.WA file MUST specify a BBSNAME. The REGISTRATION parameter is only meaningful if you've bought a registration sequence from the author. By default, DOORFILE isn't defined, which means that the door-information file must be specified on the command-line. Also, the PORT parameter is not defined, which means that comm-port info is derived from the door-information file. The other parameters default as follows: DEBUG = N REMOTECOLOR = WHITE LOCALCOLOR = WHITE PARANOID = N APDIV = 2 APMULT = 1 ABSENCES = 14 TRAINCOST = 100 TRAINSLOPE = 100 MONSTERPROB = 50 OBJECTPROB = 60 MAGICPROB = 0 MONSTERSPEED = 2 TIMEALLOWED = 60 EXTERMINATION = 250 AUTOSAVE = Y STARTBONUS = 20 AUTOVALIDATE = N SEMAPHORE = Y FRATERNITY = Y MAPPING = Y SPELLTHRESHOLD = 80 GARBAGE = 0 A sysop who wishes to favor his registered users over the unregistered ones might set up two files, one named REG.CFG and the other named UNREG.CFG. For example, REG.CFG might contain: TRAINCOST = 100 TRAINSLOPE = 100 TIMEALLOWED = 60 BBSNAME = The Example BBS REGISTRATION = 55555555 and UNREG.CFG might have: TRAINCOST = 100 TRAINSLOPE = 110 TIMEALLOWED = 10 BBSNAME = The Example BBS REGISTRATION = 55555555 HELLOMSG = You should send your sysop some money, scumbag. MAPPING = N He could then arrange his batch files so that, for registered users, REG.CFG is copied over to CONFIG.WA before WIZARD is executed. Obviously UNREG.CFG would be copied to CONFIG.WA for unregistered users. The net effect is that registered users have an easier time acquiring power, and have longer to play each day. He also would not be abused every time he came into the game.